Skip to content

Test json-aware builder #5197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

facchinm
Copy link
Member

@facchinm facchinm commented Aug 1, 2016

No description provided.

@PaulStoffregen
Copy link
Contributor

PaulStoffregen commented Aug 1, 2016

Are you sure it's a good idea to put this into the builder, rather than have the IDE which already manages platform stuff simply tell the builder which toolchain to use?

@PaulStoffregen
Copy link
Contributor

PaulStoffregen commented Aug 1, 2016

Already there's quite a lot of redundant stuff between the builder and the IDE which must be maintained perfectly in sync to avoid bugs. For example, which libraries are actually used needs to track perfectly between the IDE's File > Examples & Sketch > Include Library and what the builder will actually use when it compiles the sketch.

To illustrate the fragile nature of this situation, I believe a bug was recently added by the change to also use the library.properties architecture to alter the platform vs builtin vs sketchbook library precedence. The corresponding change wasn't made on the IDE side in how libraries are actually presented to the user by the GUI. (eventually I'll isolate this better and submit an issue with reproducible test cases, but that's going to take some time)

Duplicating this sort of subtle platform dependency stuff might require much more long-term maintenance to keep the IDE and builder using an identical set of criteria. I fear this might be making the whole system much more brittle in the long run...

@facchinm
Copy link
Member Author

facchinm commented Aug 2, 2016

Hi Paul,
you are super right, duplicating the effort and keeping things in sync is a PITA. Also, subtle differences could result in totally unexpected behaviours. Also, this PR doesn't solve the problem that the IDE still choose the wrong upload tool.

IMO, the oversimplified logic behind a lot of decisions that the IDE takes is not ready for a world with continuous updates and deployments. Small specialised tools would make the difference here, leaving the gui simple to code and to extend (which is the great advantage of Java)

In the long term, a collection of standalone tools (the builder, the uploader, the library crawler) which cooperate could fit better the great variety of situations the IDE needs to solve correctly.

For example, the library indexer could use specific OS notify methods (I'm thinking about https://fsnotify.org/) to cache the library resolution and provide snappy results. The IDE and the builder would benefit from this offload without any code duplication.

This long term strategy needs a lot of effort which we can't spend right now because the toolchain bug must be solved really soon. @cmaglie is also coding a Java only solution to address it so we can choose which solution fits better

@PaulStoffregen
Copy link
Contributor

I agree, a fix is needed urgently.

@PaulStoffregen
Copy link
Contributor

The last thing I want to do is act act an obstacle. Hopefully later there'll be an opportunity to consider the overall design....

@facchinm
Copy link
Member Author

facchinm commented Aug 2, 2016

Your contribution is invaluable so you will never be an obstacle, quite the opposite 😄 . Once the "crisis" is over we'll surely reconsider the design to make everyone happy and less bug prone

@facchinm
Copy link
Member Author

facchinm commented Aug 2, 2016

Superseded by #5199 (better, faster and non hacky solution). Closing this while leaving arduino/arduino-builder#173 open but freezed

@facchinm facchinm closed this Aug 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants